Engineering Case Library 



ECL 69A 



Computerized Traffic Control 
City of San Jose - IBM Corporation 

Abstract 

Early in 1964, the city of San Jose, California entered into a joint 
agreement with the IBM Corporation to conduct a study to determine "if it 
is functionally and economically feasible to apply a digital computer to the 
control, surveillance and evaluation of a traffic control system 11 . (Part A) 
A total of 59 signalized intersections were controlled by a centrally located 
1710 computer system (Part B) under a variety of control strategies. (Part C) 
Results of the study were such that, in July 1966, the city decided to in- 
stall a modified IBM system for the regular control of certain intersections „ 
(Part D) 



(c) 1966 by the Board of Trustees of Leland Stanford Junior University. 
Prepared at Stanford University during the 1966 National Science Foundation 
Summer Institute conducted by the Design Division, Mechanical Engineering 
Department. This case was prepared by Donald 0. Covault, Georgia Institute 
of Technology, Gerald A. Fleischer, University of Southern California, and 
Paul F. Williams, San Jose State College, participants in the Institute. 
The assistance of Mr. Paul Haddon and Dr. Albert Chang of the IBM Corpora- 
tion, and Mr. James Boring, Traffic Engineer of San Jose and Mr. Karl H. 
Vesper of Stanford University was indispensable. The permission of the 
IBM Corporation and the city of San Jose to use this case for educational 
purposes is greatly appreciated. 
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Automatic Traffic Control 

San Jose 

San Jose, California, a progressive commercial and retail center, is 
located about 50 miles south of San Francisco in Santa Clara County, Its 
population increased from 95,000 to 258,000 during the period 1950-62, had 
grown to 360,000 by mid 1966, and it is expected that the population will 
exceed 1,000,000 by 1980. 1 In 1962, the county population was 760,000 with 
approximately 420,000 registered vehicles. 

The city is governed by a Council of seven people, one of whom serves 
as Mayor, and a City Manager responsible to the Council. A number of func- 
tional departments report to the City Manager, among which is the Public 
Works Department directed by Mr. A* R. Turturici. A departmental reorgan- 
ization in January, 1965, created a Traffic Engineering Division. Jim Boring, 
Traffic Engineer and Head of this Division, reports to Mr. Turturici. 
The Traffic Engineer 

Jim Boring was born and raised in San Jose, California. After serving 

in the Navy during 1948-53, he enrolled at San Jose State College and, in 

2 

1957, received his B. S. in Civil Engineering. 3im then was employed by 
the city of San Jose, reporting to Mr. Richard Blackburn of the Street De- 
sign Division, Public Works Department. When the division was reorganized 
in January, 1965, Dick Blackburn was assigned new responsibilities in another 
division; Jim was given the title of "Traffic Engineer 1 ' and selected to head 
the newly formed Traffic Engineering Division. 



^"A minor portion of this increase is due to extension of city limits. 
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Jim's post-graduate education consists of certain night courses relating 
to Civil Engineering and, further, a period of study (1961*62) at the 
Yale University Bureau of Highway Traffic. 



3 



ECL 69A 



Some Early History 

Recognizing the pressing need for improvement in traffic conditions 
in the city— especially in the central business district (CBD)— the City 
Council authorized a traffic study to be conducted by the firm of Wilbur 
Smith and Associates, consulting engineers specializing in transportation 
problems . 

A map of the major routes at the time of the study (early 1963) is 
presented as Exhibit A-l; the traffic flow in the areas of specific in- 
terest is shown in Exhibit A-2. 

The final report of the Smith study, dated September 16, 1963, in- 
cluded the following principal recommendation (among others) : 

"Modernize existing traffic signal system, utilizing 

multi-dial, triple-offset interconnected fixed time 

3 

signal control equipment throughout. 11 
Exhibit A-3, quoted directly from the Smith study, provides additional in- 
formation relating to this recommendation. 

Dick Blackburn, Jim Boring and certain other of their co-workers had 
long considered the possibility of using electronic computers to control 
traffic signals. By late 1963, however, these engineers were aware of only 
a single precedent; a joint venture between the city of Toronto, Ontario, 
and the Traffic Research Corporation, a Canadian-based consulting firm. 
Little information about the Toronto project could be obtained at that time, 
but Jim believed that the project presumably included a digital computer for 
traffic control. Jim also knew that the equipment being used was not that 
of the IBM Corporation. 



f A description of signal control equipment is provided in Part B. 
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IBM maintains a major research and production facility within the 
city limits of San Jose. (They are located outside the central business 
district on the southern border of the city.) Account representatives are 
frequently assigned to visit local organizations, both private and govern- 
mental, in order to service existing accounts and to generate new business 
from prospective customers. 

As the result of IBM's long experience in the application of digital 
computers to process control, several of the company's representatives re- 
cognized the possibility of adapting IBM equipment to the operational con- 
trol of vehicle traffic. If this new application proved to be economically 
and technically feasible, of course, a potentially large and profitable 
marketing opportunity would result. However, by the end of 1963, no muni- 
cipal government had agreed to purchase IBM equipment for this purpose nor 
were there any active research projects directed to computerized traffic 
control . 

In November 1963, Stan Dickinson, one of IBM's local account represen- 
tatives in the San Jose area, visited Jim Boring and Dick Blackburn in Dick's 
office at City Hall. During the course of the conversation, Stan mentioned 
the possibility of forming a joint study team to investigate the possibility 
of using IBM computers (and associated equipment) to control traffic signals 
in the city. 

"Well, we've been thinking along those lines for some time ourselves, 11 
said Dick. "It sounds to me like it might prove very fruitful.' 1 

!I I like the idea, too, 1 ' Jim agreed. "Toronto is doing something along 
these lines. If we can get the support of the City Manager before the Coun- 
cil, I think that they'll go along with us. Once given the chance, I think 
this idea will prove itself." 
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After some additional discussion, they agreed to continue informal dis- 
cussions and, in the meantime, Stan would prepare a written proposal for con- 
sideration by the City Administration. 

Several weeks later, Stan forwarded a proposal in memorandum form 
(Exhibit A-4) to A. P. Hamann, the City Manager. Dick and Mr. Turturici 
had discussed the project earlier with Mr. Hamann, and so the memorandum was 
expected. 
Agreement 

Based upon Dickinson's proposal of December 13, Hamann asked permission 
of the City Council to enter into agreement with IBM to carry out a joint re- 
search study. The traffic engineers (Jim Boring and Dick Blackburn) indicated 
that, since the city "would be putting in the interconnects anyway," and since 
they would be "upgrading the system as recommended in the capital improvement 
program", the proposed research effort would "only result in an additional cost 
to the city of about $50,000 for a one-year program". Most of this expense, 
they claimed, would be due to the hiring of three electricians who would be 
used to install detectors and controllers and make other appropriate modifica- 
tions. It was also noted that, although the services of a traffic engineer 
and two computer programmers would be needed, these people were already on the 
city payroll and hence no addtional expense would be incurred. 

The City Council, at its January 1964 meeting, authorized the City Mana- 
ger to proceed with the preparation of an appropriate contract. This was done 
and, in June 1964, an agreement was signed by the city and IBM. (During this 
six month interim period, while the attorneys carried out their negotiations, 
Jim, Dick and the IBM personnel continued with their technical discussions.) 

The original contract specified completion of the project by June 1965, 
with provision for a six month extension if suitable to both parties. (Such 
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an extension indeed proved necessary, and the contract was later further 
extended through June 1966. At the time of preparation of this case- 
September 1966 — the contract had been extended once again through December 
1966.) 

According to the terms of the contract, the responsibilities of the 
two parties were as follows: 

1 . Equipment 

a. San Jose supplied: 

Detectors; controllers and their modifications; 
communication lines; communication line protec- 
tion equipment; installation and maintenance of 
all items. 

b. IBM supplied: 

The 1710 Control System; special interface equipment 
for detectors and controllers; installation and main- 
tenance of same. 

c. Jointly supplied: 

The special display panel. 

2. Manpower 

a. San Jose provided; 

Two programmers; a traffic engineer; drivers for 
the floating car; installers, maintainers and ana- 
lysts. 

b. IBM provided: 

A site manager; programmers (from 4 originally to 1 
at present); a statistician at Kingston, New York; 
a research engineer at San Jose; designers and con- 
sultants . 

3. Space 

San Jose provided: 

The computer site, at the corner of Park and River Streets, 
including furniture and air-conditioning. 

4. Other facilities 

IBM provided computer services for analysis work at San 
Jose (1401) and at Kingston, New York (7044, 7094 and 
1401). This included tapes, disks, and operators. Re- 
production facilities and secretarial assistance were 
also provided by IBM. The burglar alarm was jointly pro- 
vided by both the city and IBM. 
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Exhibit A-2 
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EXHIBIT A- 3 
Discussion of Recommendation 
Wilbur Smith and Associates, San Jose Traffic Study 

September 1963 

Traffic Signal System 

The existing traffic signal control equipment is inflexible and 
therefore unable to handle the changing traffic patterns over the course 
of a day with maximum efficiency. Because the peak hour intersection 
traffic volumes are a controlling factor in signal timing, present signal 
settings can be expected to create some inconvenience during low volume 
periods. This condition in part explains the use of flashing signals in 
the early evening hours at certain locations. In addition, the lack of 
interconnecting cable to all signal locations makes it impossible to 
coordinate all locations for progressive traffic movement. 

Approximately 50 of the study area traffic controllers are of a 
recent design permitting continued use and expansion of function. All 
other controllers should be replaced. By the addition of the necessary 
supervisory circuits and suitable jack-mounted timing units and relays, 
the 50 units can become three-cycle triple off-set controllers permitting 
variations in cycle lengths and percentage of the "green time 11 assigned 
to the approaches, and changes in timing governing the progressive 
movement of traffic. These basic changes would offer a much greater 
range of operating possibilities than is now possible. With 60 second 
cycles this program affords off-peak traffic 25 miles per hour progressions 
on selected arteries. However, the very flexibility of the recommended 
equipment suggests that subsequent day to day adjustments by the City's 
traffic engineers will finally develop the precise timing schedule for 
the most efficient traffic operation, throughout the day. 

It will also be possible to use these newer controllers, with minor 
modifications, as part of a future "traffic responsive 11 network affording 
full flexibility of operation. When the demands of traffic require the 
installation of such a system, cycle lengths, green time percentages, and 
progressions will be determined on the basis of information transmitted 
from sampling detectors to computers. Signal programs conforming to 
unexpected fluctuations in traffic will be possible. Differential off-sets 
at the signal controllers could be provided for traffic flow during inbound 
and outbound peak periods, or changes in green times for varying side street 
volumes could be programmed, for example. 

Functional supervision of the various intersection controllers can be 
accomplished by direct interconnection of cables, by means of telephone 
leased lines, by use of high frequency radio signals, or with a combination 
of these methods. The essential factor required is the provision of 
interconnection for coordination . 
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EXHIBIT A- 4 
Facsimile of 
IBM Proposal to City of San Jose 



IBM 

Data Processing Division 

1955 The Alameda 

San Jose 26, California 

Telephone: 258-2620 

December 13, 1963 

Mr. A. P. Hamann 
City Manager 
City of San Jose 
San Jose, California 

Dear Mr , Hamann: 

Earlier, this year IBM requested permission to work with the San Jose 
City Traffic Department to determine the feasibility of installing an 
advanced computer system to solve existing and future traffic require- 
ments. The results of this joint effort have resulted in the following 
conclusions : 

1. The cost of street modifications to increase traffic 
flow is becoming so costly as to negate its value in 
many instances. 

2. Better utilization of existing facilities would be 
possible if they could respond on a more timely basis 
to changes in traffic patterns, We feel that this 
potential improvement may increase street capacity 

by a significant amount thereby delaying costly major 
modifications . 

3. In order to properly solve traffic problems, the Traffic 
Department needs a better way to accumulate volume counts 
and to simulate different solutions to determine the most 
effective methods of control without having to physically 
install each system. 

We are convinced that the use of a digital computer tied directly to 
street detectors, sampling traffic flow every few seconds and setting 
the signals within a whole network offers substantial improvements in 
both performance and cost over any other available technique. 
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Mr. A. P. Hamann 
Page 2 

December 13, 1963 



But frankly, this concept has not been field tested anywhere in the 
United States. We feel that there could be strong mutual benefits 
to both IBM and San Jose City in exploring this advanced technique 
together. There has been keen interest displayed by the Traffic 
Department and it is for this reason, coupled with the nearness of 
our research facilities that makes us feel we would like to develop 
this application in San Jose. 

Basically the areas of responsibility would be as follows: 

1. IBM will provide a full-time staff of five men. 
This team has already been selected and has been 
working the past couple of months to develop a 
detailed proposal . 

2. IBM will provide a 1710 Control System computer 
that would usually lease for approximately eight 
thousand dollars per month without charge. The 
installed duration will be for the calendar year 
1964 but might be extended at the end of that time 
if mutually agreeable to both parties. 

3. The City of San Jose will provide the necessary 
street detectors, signal box modifications and 
communication lines. This cost has been estimated 
by your staff at fifty thousand dollars with at 
least 25% directly recoverable at the end of the 
study . 

4. The City would also provide the services of one 
traffic engineer and one to two programmers to 
work with our staff on a full-time basis. 

The scope of the study would be divided into two separate areas. The 
first would include San Carlos Street from the downtown area to near 
Route #17. The parallel streets of Park Avenue and Auzerais would 
be included. We would hope to have this under computer control by the 
second quarter of 1964. Phase two would deal with the downtown network. 
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Mr. A. P. Hamann 
Page 3 

December 13, 1963 



It is our intent that the study provides the following: 

1. Traffic data to your City that is not presently available 

2. Allow both of us to determine the degree of improvement 
possible using a digital computer control technique 

3. For the Traffic Department to evaluate several different 
solutions to traffic problems using the computer at minimal 
cost 

The results of this study will be the mutual property of the City and IBM 
and we trust this project will develop into a model demonstration point of 
advanced thinking and concepts being utilized to solve a problem confronting 
virtually every city in the United States* At the conclusion of this study, 
IBM will remove its equipment and the City is under no obligation to lease 
such a system. 

If for any reason the computer fails, the signals are engineered to return 
to their normal mode of operation. IBM divests itself of any responsibility 
for an accident within the control area regardless of cause. 

Also, while the 1710 system is installed, it must be restricted to the 
traffic study problem and will not be available for general engineering 
applications « 

We are preparing a detailed outline of our plans to submit to you shortly. 
But, I wanted to take the opportunity to update you on our thinking at this 
point. 

I am looking forward to sitting down with you to answer any questions that 
may have come to mind and to working with you and your staff in the months 
ahead. 

Sincerely, 

(signature) 

R. S . Dickinson 
Account Representative 
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Progress Report, 11 May 1966 
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I Computerized Traffic Control * 

City of San Jose - IBM Corporation 

In February 1964, after the initial (but not formal) decision to pro- 
ceed with the traffic control project had been made, Jim Boring started to 
seriously consider the methods and techniques under which the feasibility 
of the computer system proposed by IBM might be evaluated. There were ap- 
proximately 250 signalized intersections in the city, some of which were 
isolated from each other by several blocks whereas others were adjacent. 
Most of the signalized intersections are located in the downtown business 
district. Most of the problems which are associated with traffic movement 
and parking are also located in this area. Certain arterial streets have 
also exhibited serious problems related to traffic movement. 



Much of the material in this section dealing with equipment is taken from 
the report, M San Jose Traffic Control Project Progress", by the IBM Corpor- 
ation, May, 1966 0 



0 1966 by the Board of Trustees of Leland Stanford Junior University. 
Prepared at Stanford University during the 1966 National Science Foundation 
Summer Institute conducted by the Design Division, Mechanical Engineering 
Department. This case was prepared by Donald 0. Covault, Georgia Institute 
of Technology, Gerald A. Fleischer, University of Southern California, and 
Paul F. Williams, San Jose State College, participants in the Institute. 
The assistance of Mr. Paul Haddon and Dr 0 Albert Chang of the IBM Corpora- 
tion, and Mr, James Boring, Traffic Engineer of San Jose and Mr. Karl H. 
Vesper of Stanford University was indispensable. The permission of the 
IBM Corporation and the city of San Jose to use this case for educational 
purposes is greatly appreciated. 
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The decision to signalize an intersection is determined by Boring and 

his professional staff after first comparing the traffic characteristics of 

the intersection to be signalized with well known national warrants . If 

the intersection should be signalized when compared to the warrants, then 

the final decision to signalize is made by the staff after such items as 

cost, budgets, and other problems are considered. 

Most of the traffic controllers which were in existence consisted of 

2 

relatively old one and three-dial fixed-time controllers. There was rela- 
tively little traffic-actuated equipment being used by San Jose. 

In March 1965, the Traffic Engineering Division was formed with Boring 
as its head. The Traffic Engineering Division presently has 30 persons work- 
ing for it. Six of these persons are professional traffic engineers and the 
remaining personnel consists of technicians and clerical workers. Mr. Eugene 
Mahoney, who is in charge of the Operations Research Section of the Department, 
was assigned by Mr. Boring to work on the Traffic Control Project with Mr. Paul 
Haddon of the IBM Corporation. 

After discussions with Boring and his staff and analysis by Eugene 
Mahoney, meetings were held with Mr. Paul Haddon (Data Processing Division, 
Federal and State Government) of IBM and a plan for design of the system to be 
evaluated was made. In addition, Mr. Haddon evaluated the computer hardware 
requirements to control the selected system. This group determined that the 
study was to be divided into two phases. Phase I study was to be primarily 

2 

One-dial fixed- time controller: A controller which operates on only one al- 
location of time for red, amber, and green. This controller operates with 
one cycle time. 

Three-dial fixed-time controller: A controller which operates at different 
periods on one of three dials. Each dial may have a different cycle and a 
different allocation of time for red, amber, and green. 
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concerned with an evaluation of arterial street operation (open network) 
with computer control, and the Phase II study was to be concerned with an 
evaluation of a network of streets (closed and open network) with computer 
control. 

As shown in the diagram in Exhibit B-l, Phase I covered the first part 
of the study, which included 32 intersections, most of which were on San 
Carlos, the remainder on Auzerais and Park. Phase II included the complete 
project area, incorporating Phase I, and adding 27 more intersections, which 
were in the downtown area. Phase I used some 200 detectors, while Phase II 
required 400 detectors. 

System and Equipment Description 
General System Description 

There were many factors to be considered in the design of a traffic 
control system. The central control equipment, the communications link 
and the equipment on the street each have to be studied from a localized 
viewpoint, as well as considering their effects on the entire system. Di- 
rect costs, reliability, simplicity, maintainability and lead times must 
be weighed along with the desired functional requirements of the system. 
After making several passes using different communications schemes and de- 
vices, a decision was made by Haddon and Boring which seemed to represent 
the optimum balance for this particular situation. This decision resulted 
in a process control computer at the central site, a multi-wire communica- 
tions link to each controller and simple modifications to existing control- 
lers. Direct wire was also brought to the computer from each de teeter. 
These elements are all described in detail in this section. 
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Equipment Description 

Central Computer (Refer to Exhibit B-2) 

The IBM 1620 is the computer portion of the IBM 1710 Traffic Control 
System. This computer contains 60,000 digits of core storage which houses 
the control programs and data storage necessary to control the entire traf- 
fic network. 

All arithmetic functions, logical decisions and commands for traffic 
signal control are handled in this unit. Every device in the entire traf- 
fic complex operates under the complete and continuous monitoring and/or 
control of the IBM 1620 Central Processing Unit. 

Directly attached to (and part of) the IBM 1620 is an alphameric con- 
sole typewriter. Its primary function in this system is as an indication 
and record keeping device, 
IBM 1311 Disk Storage Drive 

The IBM 1311 is used to store the large volumes of data generated by 
the system. It also contains programs, subroutines and complete traffic 
operating tables required by the system. The disk pack is interchangeable 
with others and can store 2,000,000 digits of information. Access to the 
disk is on a random basis; a 500 instruction program can be brought into 
1620 core storage in as little time as 300 milliseconds. 
IBM 1711 Data Converter 

The IBM 1711 is an intermediate processing station. It controls the 
interrupts to the 1620 computer, and houses the pulse counters that are used 
to accumulate detector information. It also contains the Real-Time Clock 
for the system, which regulates the basic timing for the entire system. 
IBM 1712 Multiplexor and Terminal Unit 

A variety of binary devices may be actuated or entered into the IBM 
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1710 Control System via the IBM 1712 Multiplexor. Manual switches and but- 
tons may be used to control specific operations. The 1712 in this system is 
used as the terminating device for all system entry and exit points. It al- 
so contains the Contact Operating Points and Pulse Counters for the controll- 
ers and detectors. High speed Contact Sense Points are used for the main 
street green monitor. 
IBM 1443 On-Line Printer 

The IBM 1443 Line Printer is capable of printing 120 character lines at 
a rate of 150 lines per minute. In addition to listing the IBM 1710 control 
programs during the assembly process, the printer is used for the rapid print- 
ing of diagnostic and statistical information during actual control operation, 
and for the results of off-line summaries and analyses. 
IBM 1622 Card Read/Punch 

Capable of reading at the rate of 250 cards per minute and punching 125 
cards per minute, the IBM 1622 provides a convenient means of entering data 
and programs into the system. 

The punch unit of the IBM 1622 can be used to punch statistical and log- 
ging information regarding the operation of the traffic system. These cards 
can be entered back into the system (via the reader) for comprehensive statis- 
tical analysis. 
IBM 1713 Manual Entry Unit 

The IBM 1713 provides a convenient method of entering up to 12 digits 
of information into the IBM 1710 System. These 12 digits can be interpreted 
by the system as instructions, data or requests for particular system re- 
sponses. Operator entry may be initiated by the IBM 1710 Control System or 
by the operator (or engineer) located at the Manual Entry Unit. The IBM 1713 
may be located remotely from the IBM 1710 System. The 1713 has been used to 
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interrogate detector and count information, and to make changes to the system 
during the on-line progression technique. 
IBM 1715 Digital Display Unit 

The IBM 1715 provides a continuous 4-digit display to the operator or 
engineer. As with the IBM 1713, the IBM 1715 may be located remotely from 
the IBM 1710 System. The display has been used to show the requested values 
of speed, volume , stops , splits , cycle lengths and offsets after interrogation 
by the 1713. 
Display Board 

The display board was assembled by joint efforts of city and IBM per- 
sonnel. It shows a map of the control streets, and at each intersection 
there is a light which is wired directly from the relay that comes from the 
controller monitor line. The light is either green or red and indicates the 
east-west "green" condition or east-west "red", depending upon the particu- 
lar intersection under control. The board has proven most valuable in check- 
ing progressions from the computer central, and because it is wired directly, 
can be used at all times, when the computer is not controlling the system. 
There is also a row of neons that show which intersections are under, control. 
Special Interface Equipment 

Because of the distances involved, the signals from the controller moni- 
tor lines and from the detectors could not be entered directly into the 1712. 
IBM built a special relay interface that operates with a power supply to serve 
as a matching device for these signals, IBM wire contact relays are used. 
Controllers 

Pretimed, expansible controllers are installed at all intersections in 
the study areas. Prior to the study eight electronic volume-density controller 
were in use on the western leg of San Carlos Street. These controllers were 
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replaced with pretimed, expansible controllers and the electronic controllers 
either installed at non-computer controlled intersections or used as spares. 

The decision to replace these controllers was based primarily on the de- 
sire to have a three dial interconnected system for use during periods when 
the computer was not controlling the system. The city also was able to make 
good use of these units as spares for other locations. A final reason was 
that pretimed controllers are simpler to control than electronic types when 
using a computer, even though an interface for the latter was designed and 
tested. 

All the controllers are Econolite type f, F" expansible controllers or 
type "F" with flashing don't walks. Three dials are installed in each con- 
troller in an interconnected system,, The pretimed master is located at the 
computer site. During non-computer controlled periods the intersection con- 
trollers are controlled by the three dial master system, the dial currently 
in use being selected by time-of-day . 

All the controllers were modified to adapt them to computer control. 
This was done by installing three relays in each controller. One relay, the 
hold on-line relay, is used to disconnect the dial drum advance and drum re- 
lease contacts from the drum motor when the dial reaches the main street green 
key, where it rests during the computer control operation. The hold-on-line 
relay also connects the drum motor to the advance relay contacts. The advance 
relay, when operated, steps the controller drum one interval. The hold-on-line 
relay and the advance relay are operated, over the cable interconnect, by the 
contact operate relays in the computer. 

A monitor relay was added in parallel with the main street green (MSG) 
lamp, and during the MSG interval, this relay 1 s contacts are closed. This con- 
tact closure is transmitted over the cable interconnect and sensed by the contact 
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sense points in the computer. By adding these three relays the computer can 
disconnect the local controllers 1 timing circuit, step the controller through 
each interval and vary the time of each interval. It also checks the controller 
during the MSG intervals to verify that the controller has responded to each 
advance pulse sent during the previous cycle by the computer. 

If the computer senses a controller not responding to its command, that 
controller is released by the computer. The local controller then operates 
on the preselected dial, or if the controller is inoperative, maintenance per- 
sonnel are called to repair the controller. In either case, the computer prints 
a message that the computer has relinquished control over this controller and 
the time this action was taken. 

In addition to the three basic relays, several three phase controllers 
on San Carlos Street were provided with one additional computer controlled 
relay. This relay, the "all-signals-red" (ASR) relay, is used to turn all 
signal indications red while this relay is operated. This relay would be used 
to allow the computer to skip a phase when there was no demand on that phase. 
Expansion capability was provided in some controllers so that another relay 
could be added. This relay could provide two selectable special turning move- 
ments . 

By using these controller modifications, the computer can control all of 
the signal intervals and coordinate any intersection with another intersection 
or any group of intersections. Also, in the event of a computer failure or 
communications failure, the controllers will u fall back" to the three dial, 
pretimed, interconnected control system. The three dial interconnected sys- 
tem is used during non-computer controlled periods of the day. 
Detectors 

Two types of detectors are used in the Phase I portion of the project: 
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loop detectors and pressure pad detectors. For Phase II, only loop detectors 
were added. 

All detectors previously installed in the study area were incorporated 
into the project. This included all pressure pad detectors and some loop de- 
tectors in the Phase I area. In the area added to comprise Phase II, there 
were no detectors originally. 

The pressure pad detectors are all permanent, embedded, non-directional 
types that cover one lane. These detectors are primarily used to measure 
volumes in conjunction with the computer. In a few cases, they are being used 
to measure stops and delay. 

The most prevalent type of loop detector is the RCA Ve-Det 4-Pak. These 
detectors are transistorized and provide a mercury wetted relay output. The 
detector oscillator is crystal controlled and crystals of various frequencies 
are used to avoid interference between nearby loops. The detector amplifier 
senses the change in the loops 1 effective inductance due to a vehicle passage 
by a phase shift detection circuit. The phase shift detection is amplified 
and closes the output relay. Four detector amplifiers may be powered by one 
detector power supply and the amplifiers and power supply are packaged in one 
case. The loop detectors are used to measure stops, volume, delay, speed (one 
loop or paired loops), and lane occupancy, by sending their inputs to the com- 
puter which makes the calculations. 

Both the pressure pad detector and loop detector provide a contact closure 
output. The contact closure is transmitted to the central computer as a ground- 
ed signal wire. The grounded wire picks a relay at the central site, repeating 
the detector's relay closure. The relay contacts at the central site are con- 
nected to the 1710's pulse count input, and the 1710 computer interprets and 
measures these contact closures and duration of closure as speed, volume, etc. 
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The Communications System 

Every controller in the Phase I and Phase II area of the project was 
connected to the computer over communications cables. All the detectors were 
also connected to the computer by these cables. The signals transmitted over 
cables are all d.c. 96 volt pulses. Each cable is a multiconductor shielded 
cable, containing 6 pair to 100 pair of twisted number 22 gauge wire conduc- 
tors. A large conductor and the cable support are used as the communication 
common and each conductor is used with the common as an unbalanced transmission 
line . 

A voice communication system is incorporated in the cable so that project 
personnel can talk to the site from each controlled intersection. This is 
done by plugging a sound powered phone into a jack within the intersection 
controller cabinet. Four of the cable wires are used in this application, 
and are common to all locations. Each controller has a minimum of three wires 
connected to it, in addition to the system common. Each detector has one wire 
per amplifier returning to the computer, and shares the same common d.c. line 
with the controllers. 

Each wire carries only one signal. The three signals used by all controllers 
are: 1) the hold or stay-on-line signal, 2) the advance signal, and 3) the main 
street green (MSG) monitor. The hold-on-line and advance signals are trans- 
mitted from the computer to the intersection and the monitor signal is trans- 
mitted from the controller to the computer. In addition, some controllers 
have a hold-on-red signal transmitted to them so that phase skip may be ac- 
complished. Some controllers have an expansion feature allowing for a special 
phase selection, but this feature has not been used under computer control. 
Sufficient spare wires were included in all cables to allow for defective 
wires and future expansion. 
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The cable stringing was contracted by the city of San Jose to a private 
contractor. Cable routes were selected to minimize cost by utilizing exist- 
ing structures. Over 95% of the interconnecting lines were hung on existing 
utility poles or placed in existing conduits and ducts. Cables hung on util- 
ity poles were of the I.M. figure 8 type and were placed in the fire alarm 
and police communication pole positions. In the downtown area where under- 
ground ducts were available the interconnecting cable was placed underground. 
All cables terminate at the central office site into a standard telephone type 
office protector. Each signal wire in the cable is protected from lightening 
hits and power crosses by an open space cutout and from signal crosses or sig- 
nal wire grounds by a heat coil. The open space cutouts and heat coils are 
contained in the office protector and the protector also provides the termi- 
nating device for the cables. 

The following table indicates the different tasks performed by city per- 
sonnel and by contractors : 

San Jose Contractors 

Installation of wire loop pro- Installation of remaining 

totypes. Controller modifica- wire loops* 
tions . 

Detector Housing Design and in- Installation of Phase II 

stallation of Phase I Housing. Detector Housings. 

Installation of cable in quest- Installation of 90% of cables, 

ionable situations and addition- 
al locations. 

Tested detectors —bench and field. Installed 100% of new conduit 

required. 

Remodeled some equipment at 
twenty intersections. 

Several difficulties in the installation of the detectors and conduit 

occurred. Some of the detectors required extensive debugging. In addition 

the electrical workers labor union objected to non-union personnel of the 
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Traffic Engineer Division installing cables for the detector connections 
with the computer center location. These problems delayed the completion 
of the signal system hardware for six months. 

The original contract with IBM was extended six months because of the 
delays in developing the system. 
Control System Concept 

Control Systems is the name given to that class of systems which con- 
nect cause and effect into an automatic continuous operation. A simple ex- 
ample is the heating system in most private homes, where the sensing instru 
ment, or thermostat, controls the on-off condition of the furnace, which 
heats the air in the home, which then "closes the loop" by its action upon 
the thermostat. There are many different kinds of control systems, from 
the simple case just described to very complex chemical and missile systems 
However, the following four elements are common to all control systems: 

L Information Gathering 

2. Decision Making 

3. Execution and Verification 

4. Evaluation and Adjustment 

Like other unique systems, a traffic control system imposes its own 
special requirements, which modify these basic elements. These special 
requirements arise because traffic is not uniformly or permanently predic- 
table. There are significant variations that occur from minute to minute, 
as well as daily swings and long range trends. The minute to minute change 
can be observed at a particular intersection; the daily swings are a re- 
sult of patterns of business life in an area, and the long range trends usu 
ally reflect the growth of an urban area. 

These variations are not only influenced by time, but by location and 
other elements. Ball games, parades, new supermarkets, parking lots and 
weather can all affect traffic. These effects may also vary for different 
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parts of a city, and to a different degree depending upon the interaction 
of the elements. 

Working along with all these variables is the human element, which 
adds another unknown, and which may not allow nice mathematical predictions 
to function in a real life traffic environment. 

For these and other reasons, the basic control system requirements for 
traffic control are as follows: 

1. Continuous Information Gathering— to handle all of the variations. 

2. Flexible Decision Making— to respond to the variations and 
also to keep pace with the growing body of knowledge in 
timing traffic signals. Decision making should not be 
welded to a particular physical configuration. 

3. Accurate Execution and Verification— to make sure that the 
system is responding to the command. 

4. Continuous Evaluations— of both long range and short term 
variations, with the ability to make emergency or planned 
adjustments . 

More specifically, the San Jose system was designed to provide the 
following: 

1. Electrical actuation of currently installed controllers. 
Actuation is accomplished by timed pulses under positive 
computer control. 

2. Accurate timing within one second for each controller 
step. Timing methods interlock and guarantee minimum 
amber; pedestrian walk times are not violated. 

3. Synchronous phasing of all signal changes, accomplished 
smoothly and without disruption of normal traffic flow, 
when responding to changing conditions or manual in- 
structions . 

4. Automatic error recovery of a malfunctioning controller 
with provision for return to local control (with alarm- 
ing) should recovery prove impossible. 

5. Real time detection and counting of vehicles in special 
areas. Traffic counts are stored for further analysis. 
Also, calculation of density, speed and other parameters 
is performed as called for by the control program. 
Selected results can be displayed as they are occurring. 
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6. Detection of special functions , such as railroad and fire 
station activities under manual or automatic control. 

7. Automatic generation of traffic statistics, logging, error 
analysis and display of overall system performance. Log- 
ging data is in a form suitable for further detailed analysis. 

8. Allowance for safe experimentation of new methods and tech- 
niques of controlling traffic, with a minimum of new pro- 
gramming. 

9. Facilitation of communication between operators and 
traffic engineers with the entire controlling system. 
Status of the system is clearly and simply indicated at 
all times. 

10. Maximum system utilization. During slack periods, the 
system makes detailed analyses to verify correct func- 
tioning of the entire system. Further statistical analysis 
may also be performed during these periods. 

The following is added detail describing how the expanded control sys- 
tem requirements are fulfilled. 

Continuous Information Gathering *S 

To accomplish the desired control of the traffic network, certain 
information must be supplied to the computer. This required information 
may be divided into three types: functional data, timing data and general 
data. 

Functional Data 

Controller function data is maintained at all times in core storage 
of the IBM 1710 in the function tables. Each unique controller type is 
stored as a table and contains information regarding intersection lights 
that are active at each of the controller's contact positions and the cur- 
rent contact position of the controller. Dummy contact positions and any 
possible minor movements are also shown. 

Each detector is directly connected to its own individual counter in 
the IBM 1710. As each detector actuation occurs, the detector f s counter w/ 
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is incremented by one. Using certain assumptions regarding vehicle length 
and type, approximations of velocity and traffic density are made since the 
time of detector actuations can be determined quite accurately. 

Detector count information is entered into computer core storage 
when requested by the control program, and provides a complete record of 
vehicle demand and activity at each intersection. 

Timing Data 

Timing information for each intersection (and its associated controller) 
is provided in the timing tables,. One table is provided for each controller. 
Table storage also contains data relative to the controller type, cycle 
length, cycle split, offset and dwell times desired at each contact point of 
the controller. Indices of allowable variation in the timing of each phase 
and minor movements are also provided. Cycle deviation information and control 
linkage (or pointer) to the corresponding function table is given. Records 
of controllers that have been dropped by the computer, and of recovery attempts 
are maintained. 

General Data 

Information affecting the entire system includes the time of day, time 
desired to change timing tables, and the desired rate of rephasing signals. 
This data is stored in a unique area of core storage since it is referenced 
constantly by all phases of the system. 

Provision has been made to allow system operators to change any portion 
of the data or control flow of the program (subject to certain programmed re- 
strictions and system validity checks). 
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Example of a Controller Data Table 



Length 
3 



Header Table (one per controller) 
Field Name 



Controller ID 
Current Time Sequence 



Beginning Address of 
Function Table 

Total Deviation 



Required Time Leaving 
Main Street Green (MSG) 



Observed Time Leaving 
MSG 

Time Next Sequence (TNS) 



Description 



"Name" of Controller 

Address in Time Table which indicates 
current interval of the controller 

Address in Function Table of function 
for the nth intersection., 

Total timing error at this intersec- 
tion • Used for correction on succeed- 
ing cycles. 

To stay in synchronization, the con- 
troller should leave MSG at this time 
(fixes offset) . This value increments 
by exactly one cycle length. 

Actual Clock time when controller 
left MSG. 

Clock time when controller will be 
advanced. 



Flexible Decision Making 

Determination of a desired course of action is accomplished by a Master 
Control Program (MCP) . The MCP controls and directs all system subroutines 
and handles interrupts. 

As each subroutine of the computer programs completes its specific mis- 
sion, it returns control to the MCP, The MCP each second calls upon a scan- 
ning routine to determine if any signals are due for actuation based upon 
the elapsed time since the last actuation. Control is temporarily relin- 
quished to the Scanner which looks at each traffic signal ! s representation 
in core storage. Upon detecting a controller that is due for actuation, the 
Scanner places certain identification and timing data in a common communica- 
tions region of core storage and returns control to the MCP. The MCP then 
calls upon other subroutines to accomplish actuation. To date, the decision- 
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making mechanism has used both table look-up techniques and real time optimi- 
zation, and combinations of both. Table look-up is a process which selects 
signal timings from a group of tables, based upon predetermined boundary 
values of speed, volume and/or time-of-day. In real time optimization, the 
signal timings are recalculated almost instantaneously, after measuring and 
calculating traffic parameters from the raw detector information. 

All parts of the IBM 1710 Control System constantly check against a 
wide variety of limitations. In the timing of "walk" signal, for example, 
the system has a lower bound of time in which "walk" must be on (usually 7 
seconds). Within that boundary, even further restrictions may apply depend- 
ing on vehicle velocities, weather conditions, information supplied by traf- 
fic engineers (in the form of allowable values and percent deviation) and 
other considerations. 

One of the most significant constraints upon the system is that distur- 
bances must be corrected smoothly and accurately. This is accomplished by 
computer analysis of the absolute time deviation from normal of each inter- 
section for each cycle, and the application of a correction factor for the 
next cycle. A side benefit of this automatic, constant smoothing and cor- 
recting technique is that the gentle transition from one set of timing tables 
to another is accomplished by merely replacing old tables with new ones. 

The IBM 1710 System is constantly aware of all equipment, system and 
timing limitations and will operate safely within these boundaries. 

Signal timings for a two-phase operation consist of a green start time 
(offset), a green time, an amber time, and a red time. The sum of the green, 
amber, and red time is the signal cycle time. For a three-phase operation 
the timings consist of left turn green time, a green start time (offset), 
a green time, an amber time and a red time. 
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Probably one of the most significant results of this system operation 
so far has been the demonstrated ability to change decision making techniques 
without physical changes and with a minimum of programming disturbance to the 
great bulk of the programming system. This, in a time of steady technical 
growth, is extremely important. 
Execution and Verification 

The actual controlling of the traffic network is accomplished by actua- 
ting the correct controller at a pre-set time. Timing is handled by the real 
time clock of the IBM 1710 System as used by the MCP and the scanning sub- 
routine. Execution of control requires that all controllers scheduled for 
actuation be advanced as rapidly and accurately as possible. 

The IBM 1710 System actuates controllers in parallel. That is, if sever- 
al controllers require simultaneous advancement, they are all advanced by one 
"actuation" of the IBM 1710 's latching contact relays, thereby minimizing 
time spent in the controlling function. In some cases, advancement to the 
next phase is complicated by peculiarities of the controller, which may re- 
quire several commands (pulses) to advance. 

Verification of control is accomplished by a return pulse from the con- 
troller during the period at which it is in "main street green". This syn- 
chronization-return signal enables the computer to verify that it is in step 
with the operation of the controller. When the signal is sensed by the IBM 
1710, the computer verifies that the particular controller is supposed to be 
in a main street green condition. If not, a failure has occurred either in 
the controller itself or in the transmission/receiving facilities of the con- 
troller. When conflicts of this type occur, the intersection is returned to 
local control and the operator is notified. Later attempts may be made auto- 
matically at the operator's discretion to bring the controller into step with 
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the program. This is done by a normal controller restart procedure. 

Detectors are also checked for overcounting or undercounting. This is 
done by setting reasonable limits on the expected maximum value within a given 
time period, and by setting a limit on the length of time a detector can reason- 
ably be expected to have a zero count before it is considered defective. 
Evaluation and Adjustment 

There is a threefold method for evaluating the system. This consists of 
real-time computer evaluation, off-line computer evaluation and floating car 
evaluation. Real-time evaluation is the measurement and calculation by the 
computer, of parameters that are used almost immediately, for adjustment to 
the system. Examples of this are the on-line progression and micro- loop tech- 
niques that are described later. Real-time evaluation also consists of noti- 
fication to the operator of digested information, from selected detectors. 
The operator can then "tune 11 the system and make adjustments to the system by 
manually entering changes. 

Off-line evaluation is performed by studying the reports and analyses that 
are generated by the computer at off-hours, and then entering changes to the 
tables and decision making criteria to improve the system. 

The other method of evaluation for adjustment purposes is the use of the 
"floating car" which travels through the streets and times the results. 

The Programming System 

Introduction 

Since a primary objective of the San Jose Traffic Study is experimentation 
with new methods and techniques of traffic control, the computer system pro- 
gram must be as general and modular as possible. Changes in one part (or func- 
tion) of the program must be as independent as possible from others to avoid 
undesirable side effects. Changes in the method or procedure of counting and 
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detecting traffic, for instance, should have no effect whatsoever on the ac- 
tuator or driver portion of the control program. Similarly, enlargement of 
the traffic network to be controlled should only require minor changes to the 
control system. 

Isolation of the various portions of the control function is provided 
by the Master Control Program (MCP) . The logical building blocks of the con- 
trol program are not allowed to communicate directly with each other; rather, 
these blocks provide information to the MCP which, in turn, will direct the 
logical flow of information and control. 

The Master Control Program is divided into separate sections (functions) 
called subprograms which can be independently redefined or modified as re- 
quired. Some of the basic functional subprograms include: 

1. Table Changer/Optimizing Algorithm 

2. Scanner 

3. Detector Status Reporter 

4 . Advancer 

5 . Synchronizer 

6. Recovery Analyzer 
7„ Data Logger 

8. Display 

9 ■ Operator Intervention 

10. System Analysis/Performance 

11. Fallback 

The scheduling of the various functions (subprograms) is controlled by the 
Master Control Program (MCP). Exhibit B-4 illustrates this scheduling func- 
tion. 

Master Control Program Operation 

Using the Real Time Clock as a basis, the Master Control Program 
(Exhibit B-5) initiates periodic tests for a requirement to advance the con- 
trollers. These tests are performed by the Scanner, which determines if the 
right time has arrived for a stepping action, and the Detector Status Reporter, 
which examines actual traffic demands. The stepping action is then performed 
for the MCP by the Advancer. 
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The MCP receives a monitor pulse once per cycle. This pulse verifies 
the status of the lights on the street. The time at which this pulse oc- 
curs is then related to the time at which it should occur (determined by 
the cycle length and offset) and any deviation is revealed. The MCP then 
reconciles all influences which affect the action of a controller (i.e., 
operator intervention, algorithm offset changes and traffic demands via 
detectors). If the monitor pulse does not occur, the controller is returned 
to local control and the operator is notified. 
Scanner 

When called by the Master Control Program, the Scanner examines each 
intersection to see if it should be advanced (obtained from the Header Table). 
The difference is then compared with the length of time specified by the traf- 
fic engineer for that interval (contained in the Time Tables) . If this last 
comparison indicates that it is time to leave this interval, the Scanner re- 
cords this fact for the Master Control Program. 
Advancer 

The Advancer is called by the MCP to move the traffic light controllers 
through one or more intervals in their stepping mechanisms . Should this ad- 
vancing cause any intersections to leave main street green (MSG) the Advancer 
performs the additional function of insuring that the lights on the street 
are actually moving in the manner directed by the computer. The Advancer de- 
termines the condition of the lights in the intersection by examining the sta- 
tus of a MSG contact, which is closed when the MSG light in ON and open at all 
other times. 

Before advancing a controller (intersection) from MSG, the Advancer 
checks the MSG contact for closure. If an intersection fails this closure 
check, its HOLD relay is dropped (thus returning the intersection to local 
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control) , pertinent data is recorded for the Recovery Analyzer subprogram 
and the operator is notified. The remaining intersections to be advanced 
are then advanced. For those intersections which were supposed to leave 
MSG, a check is made of the MSG contacts to insure they have opened (i.e., 
actually left MSG). If an intersection fails this second check, one at- 
tempt is made to advance it. If this reoccurs during the next MSG interval 
the HOLD relay is dropped, pertinent data is recorded for the Recovery Ana- 
lyzer subprogram and the operator is notified. 

Regardless of MSG considerations, the Advancer updates the following 
records in the Header Table: 

1. Time Next Sequenced 

2. Current Time Sequence Address 

For the intersections which have just left MSG, additional entries are made 
in the Header Table: 

1. Observed Time Leaving MSG 

2. (Next) Required Time Leaving MSG. 

Control is then returned to the Master Control Program. 
Synchronizer 

The asynchronous operation on the Traffic Control Program permits one 
subprogram, the Synchronizer, to perform all synchronizing functions, in- 
cluding initial synchronization at startup, continuous damping of any ac- 
cumulated errors in the system (lagging of relay responses, etc.)> placing 
recovered controllers in synchronization, resynchronizing to a new offset 
progression pattern as directed by an Offset Table Change or an optimizing 
algorithm, etc. Moreover, the traffic engineer has control over the amount 
of correction performed in one traffic light cycle, thus insuring synchro- 
nous phasing of all signals without disruption of normal traffic flow* 

After computing the Timing Correction (defined as the difference 
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between the Required Time for leaving MSG and the Observed Time of leaving 
MSG) , the Synchronizer takes into consideration the following before compu- 
ting a final correction: 

1 . Operator Intervention 

2. Detector Counts of Actual Traffic Conditions 

3. Offset Progression Table Changes 

4. The Timing Correction 

The Synchronizer then determines whether synchronization can be achieved 
more rapidly by shortening or lengthening the cycle (i.e., speeding up or 
slowing down to get "in step" with the progression). 

Having determined the "direction" of the Total Correction, the Synchro- 
nizer examines the Time Table to ascertain which intervals in a cycle may be 
adjusted, and to what degree* (The degree is specified by the traffic engi- 
neer, who thereby fixes the maximum adjustment per cycle.) Finally, Adjusted 
Times for all necessary intervals are computed and recorded (in the Time Table) 
for the use by the Advancer. 
Recovery Analyzer 

As previously indicated, the synchronizing function involved in return- 
ing an intersection from local control to computer control is performed by 
the Synchronizer, However, it is obviously desirable to analyze the perfor- 
mance of all faulty controllers in an attempt to determine: (1) the cause 
and frequency of the failure; (2) the possibilities of on-line compensation/ 
correction; and (3) the history of system malfunctions , incorporating the 
type of failure, the corrective actions attempted and their respective effects. 
These diagnostic functions are performed by the Recovery Analyzer. 
Fallback 

Return to local control may be scheduled or non-scheduled. For the non- 
scheduled condition (system equipment failure), it is imperative to avoid 
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erratic sequencing of signal lights „ Therefore, those signals that are mal- 
functioning will be dropped to local control. 

Smooth transition from computer to local control is easily accomplished 
under normal operating conditions by Fallback subprogram. 

Before releasing control, the Fallback subprogram determines the current 
position of signal from the Main Street Monitor Line. When the signal reaches 
the beginning of main street green it will be dropped back to local control. 
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EXHIBIT £-2 SYSTEM BLOCK DIAGRAM 
Source: IBM Corporation, "San Jose Traffic Control Progress Report", Hay 1966 
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EXHIBIT B-4 MCP SCHEDULING FUNCTION 

Source: IBM Corporation, "San Jose Traffic Control Project Progress Report", May 

1966 
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EXHIBIT B-5 MASTER CONTROL PROGRAM 
Source: IBM Corporation, ''San Jose Traffic Control Project Progress Report 11 , May 1966 
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Computerized Traffic Control (C) 
City of San Jose - IBM Corporation 



Operating Criteria 

Jim Boring and Eugene Mahony outlined in detail to Paul Haddon of IBM 
Corporation the variables of traffic operation they considered of greatest 
importance, 

1. Number of Stops 

2. Delay 

3. Trip Time l 

4 . Throughput 

5. Queues 

6. Density 

7. Speed Variation 

8. Traffic Service Index - a combination of 1,2,3, and a measure 
of driver satisfaction 

Because of the nature of traffic and of these variables, it is usually 

impossible to optimize on all these variables simultaneously. Number of 

stops might be reduced simply by reducing the speed, however, trip time 

would be increased. Trip time could be reduced by restricting traffic into 

the control area. This procedure would reduce throughput. Throughput can 



"Throughput. A parameter which is a measure of the number of vehicles pass- 
ing through the signal system in a given period of time. 



(c) 1966 by the Board of Trustees of Leland Stanford Junior University. 
Prepared at Stanford University during the 1966 National Science Foundation 
Summer Institute conducted by the Design Division, Mechanical Engineering 
Department. This case was prepared by Donald 0. Covault, Georgia Institute 
of Technology, Gerald A. Fleischer, University of Southern California, and 
Paul F. Williams, San Jose State College, participants in the Institute. 
The assistance of Mr. Paul Haddon and Dr. Albert Chang of the IBM Corpora- 
tion, and Mr. James Boring, Traffic Engineer of San Jose and Mr. Karl H. 
Vesper of Stanford University was indispensable. The permission of the IBM 
Corporation and the city of San Jose to use this case for educational pur- 
poses is greatly appreciated. 
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be increased (assuming a saturated condition) by increasing the cycle 
length. Such an increase would be accomplished, however, by an increase 
in delay. 

In the San Jose System, measure of items 1,2, and 3 (above) were 
obtained from the floating car. These results, however, reflect the per- 
formance of an individual car at isolated points in the system -- not the 
performance of all cars at the same time. 

A scheme for measuring stops and delay with a digital computer was 
developed. Trip time is not feasible with a computer in a normal traffic 
environment, which allows turns on and off the main artery. Throughput, 
as a criterion, is not meaningful except in a saturated condition. Other- 
wise, it is simply equal to the demand. Queues at a given time are reflected 

2 

in the number of stops. Finally, the use of the Traffic Service Index is 
still experimental and requires the use of a floating car. 

For these reasons, it was decided, at San Jose, that the computer 
measure stops and delay for evaluation purposes, these measurements to be 
supplemented by the floating-car measurements of trip-time, stops, and delay. 
Floating Car Evaluation 

During the two weeks that each control technique was in operation, 
City personnel drove throughout the system collecting data on trip time, 
number of stops, and delay. The routes chosen were the three East-West 
arteries for the first phase of the San Jose study and as many of the North- 

2 

Using density and speed variation as criterion measures is quite difficult. 
One problem is that the measurements necessarily reflect the conditions at 
a point, or at points, whereas evaluation should be system-wide. In addi- 
tion, certain densities are good under some conditions, bad under others. 
A speed variation of zero might mean that cars are moving uniformly in pla- 
toons, or that the street is completely congested. 
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South streets as possible. Some of the North-South streets contained only 
two intersections in the control area, so that results for them are not 
very meaningful. However, it was felt that some measurements were nec- 
essary because some control techniques might achieve improvement in East- 
West flow at the expense of the North-South streets. Therefore, average 
delay and probability of stopping are analyzed for these streets. 

An attempt was made to follow a schedule so that trips made for one 
technique were made at approximately the same time of day as for another 
technique . 

Because of the amount of time involved (about six hours a day), it was 
necessary to use two drivers in the study. They attempted to drive as the 
"average" car, which is an essential part of floating car measurement. 

For a particular trip, the data recorded are trip time, number of 
stops, and delay per stop. Trip time is the elapsed time of the trip. A 
stop is counted if it is due to a traffic light in the control area. Delay 
is an estimate of the number of seconds lost due to the stop. A stop due to 
extraneous causes, such as an accident, illegally parked or turning vehicle, 
a stalled car, etc., was recorcfed but eliminated from trip time and delay. 
If these delays were excessive, the trip was discontinued and not used for 
analysis. Another cause for throwing out data was inclement weather. If 
the driver felt that poor visibility or wet pavement slowed him down, the 
data was not used. 

For analysis, a trip on a particular street was classified as to direc- 
tion and time of day. Over the two-week control period for each technique, 
the mean trip time, mean stops, and mean delay were computed. These means 
were for a particular street, direction and time, so that for one street 
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there were five means — two for direction, three for time for each 

variable, or 15 total. 

After data for two techniques were gathered, the performance of the 

3 

techniques was evaluated by performing a t-test on each pair of means. 
For one street, 15 t-tests were required. 

When all comparisons were complete, the data were summarized by em- 
phasizing significant differences. This type of summary is necessary since 
the results of several t-tests cannot be combined into a single overall 
statement. Where trade-off between control technique exists, interpretation 
becomes difficult. However, where one technique is clearly superior to 
another, this fact is usually evident from a consistent superiority. 

The floating car results are discussed in the Results section of this 
report, and enumerated in the Appendix. 
Computer Generated Evaluation Information 
How Stops and Delay are Measured 

A measure of system stops and delay can be obtained from the digital 
computer. These measurements were made at 163 detectors in the first phase 
of the San Jose study. The method of measurement was as follows: 
1. Number of stops (refer to Exhibit C-l) 

In each approach lane to an intersection we obtained from the 
detector in this lane the number of actuations between end of green 
phase less vehicle clearance time and end of red phase less vehicle 
clearance time. This formulation assumes that the detector is at a 
sufficient distance from the intersection that no cars will be queued 

J A statistical technique for determining if differences between means can be 
reasonably attributed to non-chance factors, such as real differences between 
control techniques . 



5 



ECL 69C 



behind the detector. If this is not true, all stops will not be 

counted . 

Delay 

Delay was defined as time lost at the intersection by those 
vehicles which are stopped. 
The following symbols are used: 

t^ - time at which green phase ends 

t^ - time at which red phase ends 

D - distance of detector from intersections 

V - speed of traffic in free flow 

tj - time during the interval t n - 77 and t_ - ^ at 

G V R V 

which the jth actuation occurs. 

dj - delay experienced by the jth vehicle. 

All vehicles crossing the detector between times t - — 

G V 

and t R - — are assumed to be stopped by the red light. 
The formula for delay to the first stopped vehicle is: 

d i + R - fc i -| + H i 

where R is the length of the red phase, is the elapsed time 

in seconds after t g - ^ that this vehicle crossed the detector, 
D 

- is travel time from the detector to the intersection, and H 1 

is the time lost in accelerating by this vehicle. 

For n stopped vehicles the total delay for the n vehicles is: 
n n 
D = nR - £ t -n-+ZH. . 
j-1 m V j«l J 

The computer has a running record of the second term on the right 
of this equation, and can easily compute the first and third terms. 
The final term can be determined either from a mathematical model 
or empirically. 
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n ^ 
Empirical values of Z H will vary due to composition of traffic, 

j=l 2 

turning novements, presence of pedestrians, etc. It will also likely 
vary from one intersection to another. Obtaining measurements on 
through lanes might overcome some of these difficulties. As in de- 
termining number of stops, this technique applies only when no cars 
queue behind the detector. 
Other Factors 

In addition to the previously described measurements, the following 
were measured, but not used for any overall, conclusive evaluation: 

Volume On all detectors, for each approach, by time of day, 

for each 5 minutes 
Speed Five minute averages for each of 30 detectors, 

assuming a vehicle length of 17.1 feet 

Lane 

Occupancy -- Five minute average on each of 30 detectors. 
Delay was chosen as an overall measure of effectiveness for the opera- 
tion of the signal system even though this measurement was subject to some 
inconsistencies because of variable demand and frequency at each intersec- 
tion. Delay was evaluated in two ways: 

(a) Average overall delay for all vehicles in the system 

(b) An evaluation of delay versus demand using regression techniques. 
In addition to delay the results of the floating car method were to be 

used to measure the effectiveness of the signal system. 
Systems Tested 

Haddon, Mahoney and Boring decided to test several operating systems 
as described below. The computer was made to behave like other dial systems ^ 
which normally change cycle length and other parameters based upon control by 
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a master clock. The differences was that instead of a master clock, the 
computer and its clock controlled the output to initiate these changes. 
Also, there was now a means of evaluating systems by analyzing the detector 
results . 

Generally speaking, the computer acted like the standard systems being 
tested, but provided the extra monitoring and measuring capability that is 
a unique feature of computer systems. The following traffic control schemes 
were evaluated: 

1. "Original" System 

This was a combination of vehicle-actuated controllers and a non- 
interconnected single dial system on the arteries under initial 
control. For the downtown section, an interconnected three-dial 
system was considered the "original 11 system, or reference point. 
It is important to note that both of these base line references 
were installed using computer generated input data to establish 
the timing. Therefore, the base line is actually an improvement 
of what was being used before the project began. 

2. Single Dial 

3. Three Dial 

4. Three Dial Volume Actuated 

For the above three systems, the computer used tables that were 
set up by the City of San Jose traffic engineers according to 
generally accepted traffic engineering methods. The three dial 
volume -actuated system is the same as the three dial system, 
except that it changes "dials" based upon measured traffic volumes 
rather than by a time-of-day clock. 
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Research Program I 

This technique was based upon tables that were generated by IBM 
Research Engineers at San Jose. It utilizes a "policy improve- 
ment" method which yields, by iteration, better and better syn- 
chronizing schemes, starting with some arbitrary first approxi- 
mation. The figure of merit of this method is that the total 
delay to the users of the system is minimized. This delay is 
computed by simulating the motion of cars through a system and 
taking into account the size of queues stopped at the beginning 
of the green phase. The technique was used for either arterial 
or network configurations. (See operating strategies for 
Research I for additional information.) 
On-Line Progression 

The on-line progression program was a technique developed by 
D.W. Brooks of IBM. It utilizes a program that gives a maximum 
bandwidth for progressive arterial flow. The way it is used in 
real time was to recalculate the results and install a new pro- 
gression every 15 minutes. This program also was "tuned" at the 
central location by observing the number of cars stopping at key 
intersections, and manually inserting parameter changes to mini- 
mize this number. This program was only used for a short period 
of time as a real time program because it always operated the 
signal system in the same manner over a short period of time. As 
a result, little data was obtained for this type of operation 
because it was discontinued after being used for three days. 
Micro Loop Techniques 

These techniques are used to control timings at any critical 
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intersection. There are several versions: 
Micro Loop Version IA 

This version holds the offset on the major street and adjusts 
the split only. It maintains the minimum "Walk 11 and "Don't Walk 11 
timings . 

Calling a certain level of demand on the f A 'phase lf X M , and a 
level of delay on the cross street "Y n , this algorithm works as 
follows : 

If the demand on 'A; phase is more than 'X' and the delay on 
the cross street is less than ' Y 1 , f A f phase is expanded to 
the maximum. 

If the demand on *A f phase is less than 'X 1 and the delay on 
cross street is more than 'Y', than 'A 1 phase is cut down 
proportionally to serve the cross street sooner. 

If there is no cross street requirement or if the demand on 
'A f exceeds another fixed value, then the cross street phase 
will be cut sooner; to get to 'A' phase before its normal 
offset . 

If both 'X 1 and 1 Y 1 are exceeded, the background cycle timing 
will stay in effect. 

If both 'X f and f Y' are below set values, the background cycle 
timings stay in effect. 

Micro Loop Version IB 

This technique is similar to IA, but does not try to hold the 
offset. It expands the existing phase as it is needed, and cuts the 
existing phase if the opposite demand exceeds a set level. If there 
is no opposing demand, the existing phase is expanded to a maximum 
of two cycle lengths. 
Micro Loop Version IIA 

This is a micro-loop that works with intersections that do not 
have split timing on the left turn (3rd phase). It allows for a 
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minimum of 6 seconds for the left turn lane, and extends 3 seconds 
per car up to a maximum for the left turn phase. 
Micro Loop Version IIB 

This works the same as IIA, except that it is used with split- 
timings on left turns. It will end the first ('C^ 1 ) phase as des- 
cribed above, and then operate on the split C^') phase in the 
same manner, thus possibly adding the excess time from to . 
Micro Loop Version IIC 

This version operates on all three phases. 

Five seconds before the scheduled end of the f A ! phase, the 
number of cars requiring service in all four directions for the 
next 10 seconds is measured. Stopped cars and moving cars are 
considered, and factors can be applied to weight the directions 
differently if there is a need because of peculiar local conditions. 

The computer then compares the number of cars in both direc- 
tions to determine if the current phase should be extended. As an 
example, if in 'A' phase the equation could be 

Z = 2 (east-west cars ) - 1.5 (north-south cars) 

If Z is greater than set limits, ! A ! phase is extended 5 or 10 
seconds . 

If Z is less than a set limit, it cuts of 'A; 5 seconds early. 
If Z is between certain values it stays with the background 
timings . 

This version also can set limits to stay within (5 seconds) a 
certain value of the normal offset. If there is no extension the 
program will correct toward the exact value of the offset at a pre- 
determined rate . 
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Operating Strategies for Systems 

Strategies for the operation of the "Original", "Single Dial", 
"Three Dial", and "Three Dial Volume Actuated" were specified by Jim 
Boring and Eugene Mahoney. These strategies were developed based on 
experience and standard traffic engineering techniques such as the use 
of time-space diagrams to determine signal offsets and phase times for 
arterial street flow. 

The strategies for "Research I System" was developed by Dr. Albert 
Chang of the IBM Corporation. Dr. Chang, a young electrical engineering 
graduate from the University of California, was employed by IBM in the 
Fall of 1964 immediately after completing his Ph. D. program. Dr. Chang 
was assigned the task of developing an operating strategy for the signal 
system. By the time Dr. Chang had started to work on this problem, the 
basic signal system and detector locations had been chosen. 

Chang discovered that several previous persons had treated traffic 
flow as a discrete process, i.e., individual cars in a traffic system 
were treated as part of the mathematical model development. Chang decided 
that this approach not only required very complex mathematics for model 
development, but it also required a very large computer facility to pro- 
cess rather trivial problems. Consequently, Chang treated the flow of 
traffic as a continuous process and therefore could consider the flow of 
vehicles as a mass process instead of a process whose characteristics were 
formulated in terms of individual vehicles. This approach permitted com- 
puter evaluation of the flow process and the use of less complicated models 
than would be required if traffic were considered as a discrete process. 
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4 

Using this concept Chang developed the following model. The sketch 
shown in Exhibit C-2 indicates a queue of vehicles which are waiting at 
an intersection during the red phase of a signal cycle. The number of 
vehicles flowing from intersection i to intersection j is f^(t) and the 
flow of traffic from intersection j is fjCO- The number of vehicles in 
the queue at intersection j is Jj^)* Assuming instantaneous acceleration 
of cars waiting at j and that all cars travel at constant speed v^ when 
the light turns green, the following equations were developed. 



(1.) 



Where f (t) is the flow at a point a distance x from j extending as far 
back as s, d. , is the distance from i to j, and t is the time the cars 
leave the intersection. 

Using equation (1), the queue at j at time t is given by the following 
equation: 

(2.) qj (t> = qj <0) + j {f t ^t — y-f^jOT. 

Where j depends upon the number of lanes between i and j denotes the length 
per queued car at j, is the time which can vary between the limits o,t. 
In deriving (2), the length of the queue, Pj^ 1 ")* has been assumed to be 
less than d.. in the interval (0,t). 

To develop a model for the flow variables it is convenient to think of 
flow as arising from two components. First, if the signal at j is green 



4 For more complete information, see "Synchronization of Traffic Signals in 
Grid Networks 11 by Albert Chang. Paper is to be published in the IBM Journal 
of Research and Development , January , 1967 . 
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in the direction of (k,j,) and there is no queue at j, then the flow leaving 

d 

j is the flow at i delayed by the travel time . If a queue should form 

V # , 

at j, it will give rise to a component of f once the signal has turned 
green. 

Assuming that cars leave queues at a constant rate and accelerate to 
their desired velocity in a negligible amount of time, the second component 
of flow is equal to a constant, v_., whenever Qj^O and the signal j is green. 
Note that the two components of flow are mutually exclusive because a queue 
interrupts the free flow of vehicles from the previous intersection. 
Let 1^ (t), the indicator function of q^, be defined as 



I (t) - ^ 



0 if q (t) - 0 

1 if q.(t) 0 

J 




Then, combining the two components, the flow leaving j at time t is given by 

0 if signal is red 

fj(t) = < 

In (3), the amber phase is ignored; it may be considered as part of either 
the red or green phase. 

Equations (2) and (3) were derived for intersections j in the "interior" 
of the network. For an intersection on the boundary, the flow from i in (2) 
and (3) is replaced by a source: fj^O is set equal to some prescribed 
function. In principle, the source waveforms should be chosen to match as 
closely as possible the flows observed empirically. However, except for the 
average number of cars which the source should supply per cycle, the exact 
shape of the waveform to use is generally difficult to determine. To solve 
this difficulty, the following simplifying assumption was made. Cars arrive 
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at the system boundary intersections in platoons and within each platoon the 

cars arrive separated by the same time interval. Furthermore, the temporal 

arrival pattern repeats itself from cycle to cycle. Therefore, the source 

waveforms are periodic piecewise constant functions. 

Assuming that there are no turns, the model is complete. 5 A second 
important consequence of the previous assumptions in the development of the 

models is that the solution of equations (2) and (3) is periodic for suffi- 
ciently large t. Furthermore, the periodic solution is independent of the 
initial conditions of the network. 

The synchronization problem for the signal system is considered next in 
the development of the operating strategy. One signal in the network may be 
chosen as a reference and the phasing of any other signal is determined by 
specifying the interval between the Vain street green 1 ' at the two intersec- 
tions. This interval, called the offset, may range from zero up to the period 
(cycle length) of the signals. The other signal parameter, called the split, 
is the duration of main street green. Its value is restricted by such factors 
as pedestrian crossing times. The synchronization problem is to specify the 
offset and split of each signal, within their permissable range, to accom- 
plish some objective. 

The criterion which was used to judge the performance of a set of signal 
parameters is the total steady state delay in the network which we define as 



In (4), T is the period of the signals, and the q_.(t) are the steady state 
solutions of (2) and (3) for some fixed set of sources. The sum is taken over 

^Turns can be modelled by introducing sources and sinks within the networks 
without substantially changing the theory. 



T 




q. (t)dt. 



(4) 
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all intersections and directions in the network. D is a function of the 
signal parameters alone, and the objective is to find a set of these variables 
which minimizes D. 

Because of the structure of D, there is probably no fool-proof algorithm 
for minimizing D short of evaluating all possible signal settings. As the 
latter is not computationally feasible even for moderate size networks, it is 
necessary to resort to heuristic search procedures. The procedure, which has 
been used with some success, normally consists of two stages. Usually a course 
search which may involve dividing the given network into subsystems is carried 
out first. The result obtained is then used as a starting point in a finer 
search for a local minimum of the function. 

A series of look-up tables were developed using these models which would 
specify signal setting for various source conditions. The tables were deve- 
loped using the IBM 7094 computer because a large sized computer was required 
to solve the delay algorithm. These tables were then placed in the memory of 
the 1710 computer system and called out when specific "source values" were 
measured by the detectors. 

Chang admitted that his models are far from being perfected, but he be- 
lieves that the procedure is promising and that the results obtained so far 
are encouraging. 

The models for inclusion of the micro-loops into the system were not 
developed at the time of the writing of this case because of the difficulties 
in treating the arrival of vehicles at intersections as a random process. 



^For a given cycle length for an entire system, the signal settings are the 
offset and split timings. 



Q 



V = Velocity 



— = time to travel 



D in sec 
(VCT) 



G 




R 1 


G 


R 


1 
1 
1 
1 


D 

*- v* 

V- D 

° v, 

J 


G 

i 


!'R-.D 

! v * 

! J 


'< 

R 





EXHIBIT- C- 1 MEASURING STOPS AND DELAYS AT AN INTERSECTION 
Source; IBM Corporation, "Sah Jose Traffic Control Project Progress Report", Ma/'l966 



♦direction of flow 



EXHIBIT C-2 Schematic Representation of One Direction 
of Traffic at a Pair of Intersections 
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Computerized Traffic Control (D) 
City of San Jose — IBM Corporation 

Summary of Results of Feasibility Study 

In April 1966, the IBM members of the Traffic Control Project pre- 
pared a progress report. Paul Haddon, State and Local Government repre- 
sentative of the Data Processing Division, headed up the team. Their 
conclusions concerning the benefits of computerized control of traffic 
were as follows: 

Since June of 1965, the project has been one of continuously mea- 
suring and testing both old methods and new ideas, to improve the system 
from a traffic and an operational viewpoint. This work is still continu- 
ing, and there are several new techniques that remain to be tried and im- 
proved upon. 



0 1966 by the Board of Trustees of Leland Stanford Junior University. Pre- 
pared at Stanford University during the 1966 National Science Foundation Sum- 
mer Institute conducted by the Design Division, Mechanical Engineering Dept. 
This case was prepare d by Donald 0. Covault, Georgia Institute of Technology, 
Gerald A. Fleischer, University of Southern California, and Paul F 0 Williams, 
San Jose State College, participants in the Institute. The assistance of Mr. 
Paul Haddon and Dr. Albert Chang of the IBM Corporation, and Mr. James Boring, 
Traffic Engineer of San Jose and Mr„ Karl H. Vesper of Stanford University was 
indispensable. The permission of IBM and San Jose to use this case for educa- 
tional purposes is greatly appreciated. 
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Some of the more important results and conclusions are summarized be- 
low: 

By both computer measures and through the use of timed vehicle 
operations, techniques were used that significantly improved 
traffic flow. This improvement was evidenced by reductions in 
delay and stops in traveling through the system, and also in re- 
duced trip time. 

The average delay per vehicle was reduced by as much as 147o when 
viewing the initial phase, and by larger amounts on sub-sections 
of the system. The probability of a stop was reduced by 17.8%. 

These reductions (for the initial phase of the project alone) 
result in an annual savings of more than a quarter million dol- 
lars to the motoring public. 

These improvements were extended significantly through the use 
of Micro-Loop techniques, (which concentrated on critical inter- 
sections) and through on-line progression changing. 

The feasibility of the use of a digital computer was proven for 
the traffic control application. In particular, the evaluation 
capability, the flexibility of control and the reliability of 
operation were of notable value. 

The computer proved to be a vanguard for maintenance, by indi- 
cating the approaching failures of equipment on the street before 
they became catastrophic. 

Finally, the system showed that continual improvement can be effected by 
a steady program of analysis and a study by traffic engineers. It gave traf- 
fic engineers the ability to attack problems on an overall systems basis, as 
well as at an individual intersection. It demonstrated that while much has 
been done, much more remains to be done; and that the digital computer can 
serve as an effective tool along the way. 



Average D elay 

The results of the five systems evaluated are tabulated below. 





Avg. 12 Hr„ 


Avg. 12 Hr. Delay 


Avg, Delay 


Percent 




Demand in 


In l s 000 5 000 Veh. 


Per Veh, 


Improvement 




100,0G0Veh. 


Sec, 


In Sec. 


Over Original 


Original 


5-53 


6,97 


12.6 




Single Dial 


5-62 


6,46 


11.5 


8.7 


3 -Dial (Time Act.) 


5,49 


6.20 


11.3 


10.3 


3 -Dial (Vol. Act.) 


5,93 


6,64 


11.2 


11.1 


Research 1 


5.97 


6,45 


10-8 


14.3 
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These results were corroborated by regression analysis as shown in Exhibit 
D-l. A detailed explanation of this use of regression analysis is in the 
Appendix. Even though there was some question about using delay per vehicle 
as the only criterion, Haddon felt that it gave a good representation of 
the system performance. 

Even though the floating car was used to collect a large amount of data 
and this data was subsequently analyzed for statistical significance, Haddon 
felt that the use of the floating car was somewhat inferior to the other 
means of evaluation. He gave several reasons: 

a) It did not provide continuous, twelve-hour data; 

b) At any given time it gave a picture of what is happening to 
one car at an isolated point, not a snapshot of the complete 
system; 

c) The performance of the floating car was necessarily a function 
of the driver which in no way reflects the performance of all 
kinds of drivers. 

The floating car evaluation showed that the Three Dial Techniques were 
slightly superior to Single Dial and that Research Technique I was signifi- 
cantly superior to either Single or Three Dial Techniques. 

Two other methods of comparing systems were utilized. Exhibit D-2 shows 
the percent improvement over the original system by each of the alternates 
for each intersection in Phase I. The average delay at each intersection for 
the original system and the Research System is shown in Exhibit D-3. 
Probability of a Stop 

The probability of a stop was calculated by dividing the average num- 
ber of stops by the average demand. The computer results for the original 
system and the Research Technique were as follows: 



Original 



Research 



Average Number of Stops 
Average Demand 



2.33 
4.40 



2.23 
5.12 
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Economic Evaluation of Stops and Delays 

One of the elements included in the IBM Progress Report was an analysis 
of the costs of Stops and Delays to the motoring public. They used the fol- 
lowing figures from the American Association of State Highway Officials 
(AASHO) report entitled, "Road User Benefit Analysis for Highway Improve- 
ments": The (AASHO) figures are based on 1959 cost data and nation-wide 
averages. 

Gasoline $ .32 per gallon 

Oil .45 per quart 

Tires 100.00 per set initial cost 

Time 1.55 per hour 

Car repairs and car depreciation are included. 

The AASHO cost figures for a 30 m.p.h. approach speed are: 

$.74 « Cost of a vehicle stop 
.008 « Cost after second, idling 
.043 = Cost after second, waiting 

The cost of stopped delay for the original system was calculated from 

computer data as follows: 

Average delay per stop = 23.75 seconds 

Average 12 hour demand = 553,000 vehicles 

Cost per stop = .74 + 23.75 (.008 + .043) = 1.9512 

cents per stop 

Cost per day = number of stops x cost per stop (Number 

stops = probability of a stop x 12 hour 
demand; probability of a stop = mean stops v 

mean demand 

2 H 1 9 SI 2 

Cost of stopped delay = x 553,000 x = $5713 

•n j r . . 4.40 100 

Per day for original system 

The cost of stopped delay for the Research Technique, using a similar 
calculation, is given below. For purposes of comparison, the same 12 hour 
demand figure was used, even though Research actually encountered a greater 
demand. The average delay per stop = 24.82 seconds. 
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Cost per stop = .74 + 24.82 (.008 + .043) = 2.0058 cents 
Cost per day = |^y| X 553,000 X 2 '^ 8 = $4831 

Savings per day = $882 

Savings for one year (300 days) = $264,600 

In summarizing the Economic Analysis, the IBM team made the following 
statement : 

It can be seen that reduction in the probability of a stop 
(17.8%) and the reduction in total delay resulted in extremely 
significant reductions in cost to the motoring public. It should 
be emphasized that this savings of $264,600 is only for the first 
32 intersections, and represents conservative figures for delay 
and stops, in that not 100% of those stopped are detected. Ex- 
panding the control to Phase II, and then over large areas which 
the same computer could control will result in even larger possi- 
bilities of saving. It shows conclusively that even a little at- 
tention to seemingly small improvements, in the future, can result 
in very large cost reductions. 

Proposed Operational System 

In May 1966, Jim Boring prepared a memo for the Director of Public Works 
to send to the City Manager. It recommended, on the basis of the results of 
the feasibility study, that the city adopt an operational computerized traf- 
fic-signal control system. Refer to Exhibit D-4. The Traffic Control Pro- 
ject Report prepared by the IBM team was attached to the memo. 

A. P. Hamann, City Manager, scheduled the proposal for the next meeting 

of the City Council. In anticipation, Boring prepared additional support for 

his recommendation. Financing the proposal and indirect benefits were the 

two areas on which he focused. The indirect benefits, according to Boring, 

would be as follows: 

To Budget Officials 

lo Traffic signal elements and components are becoming more 
sensitive, intricate and expensive to purchase, install and main- 
tain. In this view, the computer method would: 

a. House and protect centrally the expensive portion of the 
equipment; expose the less costly elements to weather and 
road damage or destruction by vehicle collision. 
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b. Reduce the man-hours required by people for field measure- 
ments, and field to office travel time. 

c. Increase efficiency of analytical personnel in that data 
collection and array presentations are prepared rapidly and 
automatically. 

d. Assist in reliability evaluation of field components , such 
as controllers and detectors. 

e. Tend to reduce the complexity and expense of additional 
equipment for modification of existing or new installations. 
Upgrade system by installation of less expensive field 
components . 

To City-County-State Transportation Officials 

a. The system is installed and operating. 

b. It is easily expansible. 

c. It crosses a State freeway (17 at West San Carlos). 

d. It could assist by providing traffic data for area network 
studies such as assignment studies involving integration of 
the major city streets-county expressway- state freeway 
complexes . 

e. It provides continuous data collection and means of meas- 
uring and comparing imposed network strategies. 

f. 1. Data collection characteristics are flexible: 
..•as to ease of location or relocation of individual 

field sampling points 
...as to type of field sampling detection equipment 
...as to concurrent or alternating traffic measurements 

required. 

2. Imposed control strategies including traffic parameters may 
be changed wholly or in part at a central site. 

3. Surveillance of controller and detector gear with visible 
and audible alarming is possible. 

4. Analysis and evaluation of strategy performance from 
stored data measurement and calculation arrays may be 
made, from curve or listing output. 

5. Simulation techniques are possible 

...Traffic control for construction parallel to State Freeway 
The major element in the proposed system, from a financial standpoint, 
was the IBM 1800 computer system. IBM suggested three ways for the city to 
acquire this equipment — rent, rent with purchase accruals, and the state and 
local government purchase plan. One of the factors that Jim considered in 
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evaluating these plans was the constraints placed upon different sources of 
funds by Municipal laws. Capital bonds could be used for the purchase but 
not the rental of equipment. Funds for the rental of equipment would have 
to come from general tax revenues which were limited. 

The straight rental plan was fairly simple. For a fee of $4700 per 
month the city would have possession of the equipment. Maintenance services 
would be included at this price. 

The rental with purchase accrual plan had a provision that a- portion 
of each month's rent would apply towards purchase. The monthly charge for 
this plan would have been $4825 for the first 75 months and $2181 for the 
76th month. At the end of this period, the system would become the proper- 
ty of the city. Maintenance would be provided by IBM during the rental per- 
iod. 

The state and local government purchase plan was characterized by the 

fact that the city would own the equipment immediately, but pay for it over 

60 months. The city f s payment schedule would be as follows: 

Lump Sum Initial Payment $29,193,00 
Monthly Payments, first 6 months 3,783.52 

next 12 months 3,604.61 

3,488.23 
3,371.85 
3,255.46 

last 6 months 1,238.17 
These figures include a $224.25 charge for minimum monthly maintenance. 
The list price of the 1880 system is $194,620. 

The 1800 system superceded the 1620 in the IBM product line. It was 
less expensive than the former system and had greater capacity— up to 400 
intersections. IBM will install an 1800 system, their first sale of this 
equipment for traffic control, in Wichita Falls, Texas, in late 1966. 
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In July 1966, the City Council voted to establish an operational com- 
puterized traffic signal control system as recommended by Jim Boring. The 
only discussion of the proposal concerned the site of the proposed facility. 

The regression lines for each technique show improvement at each stage 
of the experiment. Three-dial, time actuated, improved over single dial; 
three-dial, volume actuated, improved over three-dial, time actuated; Re- 
search Technique I improved over three-dial, volume actuated. The chart shows 
that the nature of the improvement is highly desirable, in that the greater 
savings in delay are realized at the high volumes. 

The number of points for each regression line is determined by the 
number of cycles for all days that the technique was tested. The smallest 
number for any technique is 145,000, so the statistical significance of the 
results cannot be questioned. 




Three Dial 
Volume Actuated 
Research Technique One 



Exhibit D-l Regression Analysis 



Demand (Cars/Cycle) 
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CITY OF SAN JOSE — MEMORANDUM 



FROM A. R, Turturici 

Director Public Works 
DATE Hay 26, 1966 



Wilbur Smith ^nd Associates, upon completion of an intensive traffic and 
p^r'tins study, submitted to the City a report entitled n San Jose Central Business 
District Traffic Study," One of the recommendations in this report was that the 
ci.;'f:fsl system in the Central Business District be modernized by interconnecting 
th<r.» signals and installing three dial, fixed time controllers, 

A fixed time system has several drawbacks in traffic control. It is not 
r^rpomiive to changes in traffic flow. It cannot adjust itself to handle variable 
pov. : loads due to special events such as special sales, parades and Civic auditorium 
.trtractions. On the other hand, the existing traffic responsive systems were very 
:;.:pcnGive, requiring a complete change of all local controllers to make it 
o ;>;.'<: rble. 

Considering these items, a joint traffic control project in cooperation with 
I.S.1 1 . was undertaken. The primary purpose of the project, as stated in the 
^;.reement with I.B.M. , was to determine if it would be functionally and economically 
i visible to use a digital computer for traffic control. 

The signals in the Central Business District have been frequently under 
computer control during the past year demonstrating that it is feasible to 
operate the signal system with the computer. With the new line of computers, 
the Model #1800 in particular, the capitol outlay required to install a traffic 
responsive system controlled by the computer is less than previously used systems. 
It has been demonstrated that under computer control there is less vehicle delay 
in the system which in turn provides greater capacity to the street system. Thtrs, 
w$ have, at last, a machine x^hich can do more efficiently that which almost all 
signals were installed to do; that is, aportion the intersection right-of-way in 
relation to the demand. 

Other services that the computer systera will offer that no other traffic control 
equipment can duplicate are: 

1. Continuous surveilance of both street traffic conditions and equipment 
operations, 

2. Provide central site for traffic monitoring and control changes which 
reduces the need for counting and observing personnel on the street 
corner. 

3. Evaluate data collected to provide information on quality of traffic 
flow, 

4. Process traffic flow data from all parts of the City which will be fed 
in by radio (the radio system is in operation). 



TO A. P, Hainan n, City Manager 
■:;C'1J£CT Computer Traffic Control 
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?<~ 0 e 2- Computer Traffic Control 



May 26, 1966 



It is anticipated that the computer will be required to operate signals 
c •;.;;«: ox inately 12 hours a day. The exact tine depends on special events which 
would require extra tine. This will sllo T .» the machine to be available several 
hoars a day to be used for other programs such as traffic assignment, accident 
analysis, engineering calculations, maintenance programming and many others. 

It is recommended that: 

1. The present computer be kept operational until the expiration of the 
City's agreement with I.B.M. (January 1, 1967) - $17,000. 

2. A firm order be placed for a model #1800 computer to be delivered in 
December 1966; to be paid for on a State and local government purchase 
plan requiring a $30,000 down payment and approximately $3,700 a month. 

3. A site to be prepared in the Civic Center area for a traffic control 
site as the existing location must be vacated shortly. (An existing 
duplex or acquire another within the area of Civic Center expansion). 
Existing building modified - $10,000; Purchase building and modify - 



4. An agreement be entered into with P. T. & T. to lease underground duct 
space to bring the interconnect to the Civic Center - $1,500 a year. 
Install interconnect cable to Civic Center * $50,000. 

5. The classification of Computer Programmer be established and the two 
persons doing this job now be reclassified - no cost. 

The cost to set up the traffic control site at the Civic Center is the 
sa;ae regardless of the type of traffic responsive control system used. The 
total cost of installation would be approximately $90,000 if City-owned structure 
is used, The cost would be increased by approximately $50,000 if additional property 
is acquired. 

The accompanying reports are for you and the City Council and describe the 
project and its benefits in more detail. 



$60,000. 



Respectfully submitted, 




Director of Public Works 



AXT:JWB:vcj 
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Appendix 

(Source: IBM Progress Report, May 1966) 

The Use of Delay in Evaluating Systems — Regression Analysis 

A comparison of two control techniques on stops or delay, would be 
meaningless without taking into account the number of cars requiring ser- 
vice (demand) . The question arises as to how to take this variable into 
account. One possibilit y (which has been used by traffic engineers) is to 
divide the total number of stops by the total demand and use this figure for 
comparison purposes . 

This figure of probability of a stop, or delay per vehicle, is not 
entirely satisfactory because of its dependence on fluctuations in demand. 
Consider the following results, for two imaginary techniques, A and B, 



Technique A — Cycle Length = 60 seconds 


Demand 


Frequency of 


Delay 


Delay 


Cars/Cycles 


Occurrence 


Sec/Cycle 


Sec/Vehicle 


2 


20 


20 


20 


4 


20 


60 


15 


6 


20 


100 


16 2/3 


8 


20 


140 


17 1/2 


400 cars total demand 



Technique B — Cycle Length = 60 seconds 


Demand 


Frequency of 


Delay 


Delay 


Cars/Cycle 


Occurrence 


Sec/Cycle 


Sec/Vehicle 


2 


16 


20 


10 


4 


20 


60 


15 


6 


20 


100 


16 2/3 


8 


21 


140 


17 1/2 


400 cars total demand 
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Here, we have two techniques where the only difference is that the 
frequency of occurrence of demands changes. The delay per cycle and de- 
lay per vehicle for each level of demand are unchanged. The important 
feature to note is that each technique handles the same demand in the same 
manner. A driver who is in a platoon of 2, 4, 6, or 8 vehicles will ex- 
perience the same delay regardless of which technique in in operation. A 
traffic engineer forced to choose between the two techniques might just 
as well toss a coin. He cannot be expected to anticipate the frequency 
of occurrence of each level of demand, especially when random deviations 
can have a marked effect on the criterion he is considering 0 

Apparently, the imaginary techniques, A and B are performing equally. 
Let us examine total demand and total delay. 

For Technique A total demand is: 20 (244+6+8) = 400 cars 
Total delay is: 20 (20460+100+140) = 6400 sec. 
The delay per vehicle is then 16.0 sec. 

For Technique B total demand is again 400 cars. 
Total delay is 6460 sec. 
Delay per vehicle is 16.15. 

This difference does not appear to be great. However, considering 
that we are dealing with vehicles in the hundreds of thousands, it takes 
on more significance. Thus, we can see that a difference in average de- 
lay per vehicle can exist, which may not be meaningful in the way traffic 
demands are being handled. 

Let us examine a somewhat more drastic result for our imaginary Tech- 
nique B. 



Technique B— Cycle Length = 60 seconds 


Demand 


Frequency of 


Delay 


Delay 


Cars/Cycle 


Occurrence 


Sec/Cycle 


Sec/Vehicle 


2 


4 


20 


10 


4 


11 


60 


15 


6 


26 


100 


16 2/3 


8 


24 


140 


17 1/2 
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Total demand = 400 Vehicles 
Total delay = 7600 sec. 
Delay/Vehicle = 16.75 sec* 

As compared to Technique A, B yields 4.7 per cent greater delay per 
vehicle with total demand, delay per cycle and delay per vehicle for each 
individual cycle remaining constant. 

The question is not so much as to how likely demands are to fluctuate — 
but that with two techniques yielding results which traffic engineers con- 
sider identical a method which concludes that they are identical is preferred. 

One method of analysis commonly used to accommodate fluctuations on an 
independent variable is regression analysis . It is the equivalent of elimi- 
nating the effect of an independent variable X on a dependent variable Y. 
Regression analysis, in this context is accomplished by plotting each indi- 
vidual demand against each individual delay. The best fit straight line which 
fits these points is then determined by the least squares technique, and this 
line represents the performance of the technique for which it was determined. 

All three examples given thus far (one for Technique A, two for Technique 
B) would result in coincident regression lines. The average delay per vehicle 
would not, however, be the same. These figures are fictional, but they were 
chosen to show the limitation of using only average delay/vehicle . 

We might consider other cases which would give identical results. The 
most general case would be for the line which passes through the mean delay 
for all levels of demand, and the variability is constant for each level of 
demand 0 

The efficacy of the linear regression line depends upon how well the 
line fits the data. This refers, of course, to its efficacy in represent- 
ing system performance, not as compared to using delay per vehicle only. 
At worst, it would yield a line parallel to the X-axis, indicating that de- 
mand has no effect on delay. In this case, the delay per vehicle could still 
be used. 
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A test of goodness of fit of the linear regression line can be performed, 
either by analysis of variance, or by hypothesizing some form of non- linear 
fit, such as a parabola, exponential, etc. The analysis of variance technique 
merely informs you that the straight line does (or does not) fit very well. 
If it does not fit, you still do not know what type of curve does. To test 
a specific type of curve, it is necessary to determine the parameters of that 
curve by a technique like the least squares approach, plot the resulting curve 
and compare it to the line obtained by linear regression. 



The total savings in delay would be for each demand level, the differ- 
ence between ordinates multiplied by the frequency of occurrence of that de- 
mand. 

One method of equating the two scales is to divide both demand and de- 
lay by the cycle length, and "plot" the resulting numbers. We would have a 
plot of demand in cars per second versus delay in seconds per second. This 
plot is somewhat more difficult to interpret and does not lend itself readily 
to a reconstruction of the total delay. However, in a truly adaptive system, 
where the cycle length changes frequently, such an approach may be necessary. 

The advantages of using average delay per vehicle are the convenience 
with which it can be computed and its ease of interpretation. However, it 
is with regard to the latter that care must be exercised. A statement such 
as one technique results in ten per cent less delay than another does not 
give the complete picture. 

Limitations of Regression Analysis 

In addition to the possibility of non-linearity, other cautions should 
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be observed in the application of regression analysis. This results from 
the fact that different control algorithms may have different cycle lengths, 
and the comparison should not be made directly. 



Consider the case where algorithm A uses a 60 second cycle while B 
uses a 120 second cycle, and the results over a ten-minute period are as 
follows : 



Technique A (C = 60 sec.) 




Technique B (C = 120 sec.) 


Demand 


Frequency of 


Delay 




Demand 


'Frequency of 


Delay 


Cars/ 


Occurrence 


Sec/ 




Cars/ 


Occurrence 


Sec/ 


Cycle 




Cycle 




Cycle 




Cycle 


2 


2 


16 




4 


1 


32 


3 


2 


30 




6 


1 


60 


4 


2 


44 




8 


1 


88 


5 


2 


58 




10 


1 


116 


6 


2 


72 




12 


1 


144 



Over the full time of operation (ten minutes) each technique handles 
40 cars with 440 seconds delay. Technique A would handle, for two successive 
cycles, the same demand with the same delay that B would handle, with twice 
the demand with twice the delay. Apparently, the two techniques are equally 
effective in handling the traffic. Plotting the two regression lines would 
result in identical slopes, but the intercept for B would be twice that for 
A. Therefore, some adjustment is required. 

If the intercepts for the two techniques are both zero, no adjustment is 
necessary. A direct comparison can be made on the slopes of the regression 
lines . 



INSTRUCTOR'S NOTES 
to 

Accompany 

CITY OF SAN JOSE - IBM CORPORATION 
Computerized Traffic Control 
(Parts A, B, C, and D) 
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Introduction 

It is in the nature of any case study that there are no readily 
defined, specific ,! solutions 11 to problems raised by circumstances of 
the case. (Indeed, problem definition may provide the greatest 
difficulty in certain instances.) These "Ins true tor 1 s Notes 11 , are 
intended as a set of suggested guideposts which may be used to focus 
upon some of the central issues which we believe to be raised here. 
Individual instructors will emphasize some of these issues and 
disregard others; and some instructors will undoubtedly focus upon 
entirely different problems. In any event, we hope that these brief 
remarks will prove helpful. 

Pedagogically , this case may be used to illustrate a number of 
issues, among which are the following: 

1. governmental decision making (capital investment, technical 
features) 

2. evaluation of alternative strategies for traffic control 

3. economic evaluation of traffic-oriented capital investment 
project 

4. marketing an existing product for a new application 

5. history of joint private industry- government research 
activity 

6. critical discussion of validity of certain statistical 
techniques . 



D. 0. Covault 
G. A. Fleischer 
P. F. Williams 



Palo Alto, California 
September, 1966 
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Part A: The Decision to Enter into Joint Agreement 

1. Specifically, what decisions were made by 11 the City 11 and who was 
responsible for these decisions? 

2. Why did Blackburn suggest that IBM, rather than his office, prepare 
the proposal? 

3. Should the City and IBM have entered into the agreement to study 
the feasibility of computerized traffic control? Why? 

4. What were IBM's interests in the study? What had they to gain 
or lose? 

5. What were the economic aspects of the City's involvement? Do the 
cost projections seem reasonable? 

6. What may be said about the economy study (or lack thereof) used 
to support decisions? 

7. Discuss the problems of risk and uncertainty associated with the 
decision to enter into the joint agreement. 

8. What are the possible advantages and disadvantages of controlling 
traffic with an electronic computer? 

9. Was the system selection (Exhibit A-5) envisioned in the spring of 
1964 compatible with the stated objectives of the study? 

10. Are frequent delays and extensions of deadlines common occurrences 
in development programs? 
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Part B: Description of Control System 

1. Discuss the decision to divide the study into Phases I and II, 

2. Discuss the selection of equipment, both for use in the computer 
control center and field installation. 

3. What criteria should have been used to determine which intersections 
should be included in the study? 

4. What criteria should have been used to select the equipment for use 
in the study? 

5. Note the techniques used in the study to measure traffic volume and 
speed. What other means might be used to this end? 

6. Do you think that the decision to utilize existing controllers was 
appropriate? Why? 
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Part C: Control Strategies 

1. Evaluate the control strategy, "Research 1", devised by Dr. Chang. 

2. Note that Dr. Chang did not join the study team until June, 1964. 
What would have been the effect, if any, if he had been on the 
project six months earlier? 

3. Was Dr. Chang's use of vehicle delay as the figure of merit 
appropriate? Under the circumstances, would some other figure 
of merit have been more "suitable"? Why? 

4. In addition to those systems (operating strategies) described in 
Part C, what others might be used? 

5. Do you believe that the "floating car method" of evaluation is a 
suitable means of measuring the effectiveness of a given traffic 
control system? Suggest improvements, if possible. 

6. Would you suspect that any or all of the control strategies 
decribed in Part C would result in a significant improvement 
over the "original system" ? If so , by how much? 



iv 



ECL 69 



Part D: The Decision to Adopt an Operational System 

Make a critical evaluation of the regression analysis as discussed 
in the Appendix. 

It is claimed that the Research I strategy results in a 17.87 D 
reduction in probability of a stop over the original system. Does 
this claim appear to be justified? 

Evaluate the "economy study 11 used to substantiate the savings of 
$250,000. Note that no provision has been made for traffic growth 
and, further, that no recovery of capital costs or annual maintenance 
and operating costs have been included. 

In particular, in (3) above, note the effect of using the time value 
of $1.55 per hour. What is the historical basis for this value? 

What may be said of Jim's evaluation of the alternative ownership/ 
lease plans? 

What justification was given for ignoring the "floating car data" ? 
Is this reasonable? 

Do the results of the pilot program appear to justify the new 
commitment? 

Given that the City approved the new program, what effect, if any, 
might this have on the future development of the City's traffic 
signal system? 

Will the City be able to continue on its own without the direct 
assistance of IBM personnel? Why? 

What might the City do with its unused computer time? (See Exhibit D-4) 

At the time of preparation of this case, organizational responsibility 
for the computer center had not been definitely established. Should 
the new director report to Boring? Turturici? Someone else? Discuss 
the ramifications of this decision. 

What decision rules might be used to select additional intersections 
for inclusion in the system? 

What market potential would you expect for IBM in this area of 
computerized traffic control? Why? 



